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DETAILED ACTION 

1. This office action is responsive to amendment of application No. 10/773,298 filed 
on 12/07/2007. Claim 8 has been cancelled. Claims 1-7 and 9-20 are pending and 
have been examined. 

Response to Arguments 

2. Applicants arguments with respect to claims 1-20 have been considered but are 
moot in view of the new ground(s) of rejection. 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. Claims 1-4, 6, 7, 10, 12, 14, 16, 17, 19, and 20 are rejected under 35 U.S.C. 
103(a) as being unpatentable over ISO/IEC 13818-6 (First edition 1998-09-01), in view 
of JERDING et al. (2006/0206913), and further in view of Goffin, II (US 6,918,135). 

Consider claim 1, ISO/IEC 13818-6 teaches a method for controlling 
network digital broadcasting service (P. xix {0. Introduction}, 2 nd paragraph, 
Described further in detail in Clause 4), comprising steps of: 

directly requesting, at a client, a SRM (Session Resource Manager) for a 
session connection, and establishing a session by receiving a confirmation 
message for the session connection from the SRM ("Network" referred to here 
refers to "SRM" as shown in Fig. 0-1 on P.xx, since clause 4 relates to User to 
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Network Session Messages as stated in the contents on P. iii. P. 76 Step 1 
teaches "the Client shall send ClientSessionSetUpRequest to the Network..." to 
establish a new session connection. P. 78 Steps 7-8 teaches the client receiving 
a ClientSessionSetUpConfirm message from the SRM establishing the session 
connection. As seen on Fig. 4-6, the client is directly sending and receiving 
messages from the SRM); and 

directly requesting, at the client, the digital broadcasting server for a 
channel change, and changing a channel by receiving a confirmation message 
for confirming the channel change from the digital broadcasting server (P. 492- 
495 teaches a client directly requesting a broadcast program from the SDB 
Server. A SDBProgramSelectRequest is generated by the client and sent to the 
SDB Server for requesting a channel change. A SDBProgramSelectConfirm 
from the SDB Server is received by the client allowing the client to receive the 
requested Broadcast Program), 

wherein a message for requesting the channel change and the 
confirmation message for confirming the channel change each include a DSM- 
CC (Digital Storage Media-Command and Control) message header field (P. 
492-493; Fig. H-4. protocolDiscriminator, dsmccType, messageld, transcationld, 
reserved, adaptationLength, messageLength make up a DSM-CC message 
header field as taught in clause 2 on p. 7, which are all present in both messages 
for channel change and confirmation. P.291 Sections 10.1.2-10.2), the message 
for requesting the channel change is a ProgramSelectRequest message 
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including: a DSM-CC (Digital Storage Media-Command and Control) message 
header field (P. 492-493; Fig. H-4. protocolDiscriminator, dsmccType, 
messageld, transcationld, reserved, adaptationLength, messageLength make up 
a DSM-CC message header field as taught in clause 2 on p. 7, which are all 
present in both messages for channel change and confirmation. P.291 Sections 
10.1.2-10.2), a Session ID (Identification) field, a broadcast Programld field, and 
the ProgramSelectRequest message is transmitted from the client to the digital 
broadcasting server (Table 10-5, P.293 Section 10.2.3.1). 

ISO/IEC 13818-6 does not teach that the SRM (Session Resource 
Manager) can also reside at the digital broadcaster server, 

the ProgramSelectRequest message includes a STB (Set Top Box) status 
field, and a Client ID field. 

In an analogous art JERDING teaches session setup and controlling video 
distribution between server and client. JERDING also teaches a SRM (Session 
Resource Manager) that resides at the digital broadcaster server (cable 
headend) (Fig. 2, Paragraph 0037 teaches where both the MOD application 
server 19 and the digital network control system {DNCS, SRM} are both located 
at the cable television headend 11). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6 to include the SRM at the cable 
headend, as taught by JERDING, for the advantage of providing the cable 
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service providers with greater control and manageability over the broadcasting 
infrastructure. 

ISO/IEC 13818-6 and JERDING teaches a ProgramSelectRequest 
message (ISO/IEC 13818-6 - P.293 Section 10.2.3.1), but do not explicitly teach 
the message includes a STB (Set Top Box) status field, and a Client ID field. 

In an analogous art Goffin teaches, a channel request message includes a 
STB (Set Top Box) status field, and a Client ID field (Col 3: lines 49-61, Col 4: 
lines 49-51 teaches transmission of video from a headend and a data router 202 
that facilitates headend communications with the client device. Col 5: lines 34-44 
and Col 6: lines 14-24 teaches that the data router 202, receives both the STB 
status and client ID from the client device). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6 and JERDING to include a STB (Set 
Top Box) status field, and a Client ID field with the channel change request 
message, as taught by Goffin, for the advantage of notifying the server of the 
state and requests of the STB, and also allowing the server to easily and readily 
determine the source of the message. 



Consider claim 17, ISO/IEC 13818-6 teaches a system controlling a 
network digital broadcasting service (P. xx Fig. 0-1, sP. xix {0. Introduction}, 2' 
paragraph, Described further in detail in Clause 4) comprises: 
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a client and a SRM (Session Resource Manager), the client directly 
requesting the SRM (Session Resource Manager) for a session connection, and 
establishing a session by receiving a confirmation message for the session 
connection from the SRM (Session Resource Manager) ("Network" referred to 
here refers to "SRM" as shown in Fig. 0-1 on P.xx, since clause 4 relates to User 
to Network Session Messages as stated in the contents on P. iii. P. 76 Step 1 
teaches "the Client shall send ClientSessionSetUpRequest to the Network..." to 
establish a new session connection. P. 78 Steps 7-8 teaches the client receiving 
a ClientSessionSetUpConfirm message from the SRM establishing the session 
connection. As seen on Fig. 4-6, the client is directly sending and receiving 
messages from the SRM); and 

the client directly requesting a program change from the digital 
broadcasting server and receiving a confirmation message from the digital 
broadcasting server, when the digital broadcasting server confirms the program 
change (P. 492-495 teaches a client directly requesting a broadcast program 
from the SDB Server. A SDBProgramSelectRequest is generated by the client 
and sent to the SDB Server for requesting a channel change. A 
SDBProgramSelectConfirm from the SDB Server is received by the client 
allowing the client to receive the requested Broadcast Program), 

wherein a message for requesting the channel change and the 
confirmation message for confirming the channel change each include a DSM- 
CC (Digital Storage Media-Command and Control) message header field (P. 
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492-493; Fig. H-4. protocolDiscriminator, dsmccType, messageld, transcationld, 
reserved, adaptationLength, messageLength make up a DSM-CC message 
header field as taught in clause 2 on p. 7, which are all present in both messages 
for channel change and confirmation), the message for requesting the channel 
change is a ProgramSelectRequest message including: a DSM-CC (Digital 
Storage Media-Command and Control) message header field (P. 492-493; Fig. 
H-4. protocolDiscriminator, dsmccType, messageld, transcationld, reserved, 
adaptationLength, messageLength make up a DSM-CC message header field as 
taught in clause 2 on p. 7, which are all present in both messages for channel 
change and confirmation. P. 291 Sections 10.1.2-10.2), a Session ID 
(Identification) field, a broadcast Programld field, and the ProgramSelectRequest 
message is transmitted from the client to the digital broadcasting server (Table 
10-5, P.293 Section 10.2.3.1). 

ISO/IEC 13818-6 does not explicitly teach that the SRM (Session 
Resource Manager) can also reside at the digital broadcaster server, 

the ProgramSelectRequest message includes a STB (Set Top Box) status 
field, and a Client ID field. 

In an analogous art JERDING teaches session setup and controlling video 
distribution between server and client. JERDING also teaches a SRM (Session 
Resource Manager) that resides at the digital broadcaster server (cable 
headend) (Fig. 2, Paragraph 0037 teaches where both the MOD application 
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server 19 and the digital network control system {DNCS, SRM} are both located 
at the cable television headend 11). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6 to include the SRM at the cable 
headend, as taught by JERDING, for the advantage of providing the cable 
service providers with greater control and manageability over the broadcasting 
infrastructure. 

ISO/IEC 1 381 8-6 and JERDING teaches a ProgramSelectRequest 
message (ISO/IEC 13818-6 - P.293 Section 10.2.3.1), but do not explicitly teach 
the message includes a STB (Set Top Box) status field, and a Client ID field. 

In an analogous art Goffin teaches, a channel request message includes a 
STB (Set Top Box) status field, and a Client ID field (Col 3: lines 49-61, Col 4: 
lines 49-51 teaches transmission of video from a headend and a data router 202 
that facilitates headend communications with the client device. Col 5: lines 34-44 
and Col 6: lines 14-24 teaches that the data router 202, receives both the STB 
status and client ID from the client device). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6 and JERDING to include a STB (Set 
Top Box) status field, and a Client ID field with the channel change request 
message, as taught by Goffin, for the advantage of notifying the server of the 
state and requests of the STB, and also allowing the server to easily and readily 
determine the source of the message. 
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Consider .claim 2, ISO/IEC 13818-6, JERDING, and Goffin teach 
receiving, at the client, a message for checking a status of the client from the 
digital broadcasting server, and directly delivering a confirmation message for 
checking the status of the client to the digital broadcasting server (ISO/IEC 
13818-6 - P.90-91 teaches that the client can receive a ClientStatuslndication 
message sent from the SRM which requests information. The client in turn 
sends back a ClientStatusResponse containing the information that was 
requested. Referring back to Table 4-16 on P.56, many different statusType 
fields can be used for specifying what type of status is requested including the 
status of the client. JERDING - Paragraph 0037 teaches that the SRM can be 
located at the cable headend {digital broadcasting server}). 

Consider claim 3, ISO/IEC 13818-6, JERDING, and Goffin teach directly 
requesting, at the client, the digital broadcasting server for a session termination 
and terminating a session by receiving a confirmation message for the session 
termination from the digital broadcasting server (ISO/IEC 13818-6 - "Network" 
referred to here refers to "SRM" as shown in Fig. 0-1 on P.xx, since clause 4 
relates to User to Network Session Messages as stated in the contents on P. iii. 
P. 81-82 teaches a client initiating a release request. Step 1 teaches the client 
directly sending a ClientSessionReleaseRequest message to the SRM for 
releasing an existing session. Step 4-5 teaches receiving a 
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ClientSessionReleaseConfirm message from the SRM terminating the session. 
JERDING - Paragraph 0037 teaches that the SRM can be located at the cable 
headend {digital broadcasting server}). 

Consider claim 4, ISO/IEC 13818-6, JERDING, and Goffin teach directly 
requesting, at the digital broadcasting server, the client for a session termination 
and terminating a session by receiving a confirmation message for the session 
termination from the client (ISO/IEC 13818-6 - P. 87 - 88, step 2 teaches 
sending a ClientSessionReleaselndication to the client for releasing an existing 
session. The SRM receives the ClientSessionReleaseResponse from the client 
and releases all the resources assigned to the session terminating the session 
for the client. JERDING - Paragraph 0037 teaches that the SRM can be located 
at the cable headend {digital broadcasting server}). 



Consider claim 6, ISO/IEC 13818-6, JERDING, and Goffin teach teaches 
wherein a protocol between the client and the digital broadcasting server is a 
TCP/IP (Transmission Control Protocol/Internet Protocol) (ISO/IEC 13818-6 - P. 
xxv teaches that the transport layer in Fig. 0-3 on P. xxiv may consist of any 
protocol including TCP over IP. P. 291 also teaches that Switched Digital 
Broadcast (SDB) Channel Change Protocol (CCP) can be carried on top of 
various protocols including IP where their constraints are further defined in 
clause 9, allowing for the use of TCP over IP). 
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Consider claim 7, ISO/IEC 13818-6, JERDING, and Goffin teach wherein 
a message for requesting the session connection is a SessionSetupRequest 
message including: a DSM-CC (Digital Storage Media-Command and Control) 
message header field, a Session ID (Identification) field, a Reserved field, a 
Client ID field, and a Server ID field, (ISO/IEC 13818-6 - 4.2.4.1 on P. 25-26, and 
Table 4-8) and the SessionSetupRequest message is transmitted from the client 
to the digital broadcasting server (ISO/IEC 13818-6 - "Network" referred to here 
refers to "SRM" as shown in Fig. 0-1 on P.xx, since clause 4 relates to User to 
Network Session Messages as stated in the contents on P. iii. P. 76 Step 1 
teaches "the Client shall send ClientSessionSetUpRequest to the Network..." to 
establish a new session connection. As seen on Fig. 4-6, the client is sending 
and receiving messages from the SRM. JERDING - Paragraph 0037 teaches 
that the SRM can be located at the cable headend {digital broadcasting server}). 

Consider claim 10, ISO/IEC 13818-6, JERDING, and Goffin teach 
wherein a message for requesting a session termination is a 
ClientReleaseRequest message including: a DSM-CC (Digital Storage Media- 
Command and Control) message header field, a session ID field, a Reason field 
(ISO/IEC 13818-6 - P.28 Section 4.2.5.1), and the ClientReleaseRequest 
message is transmitted from the client to the digital broadcasting server (ISO/IEC 
13818-6 - "Network" referred to here refers to "SRM" as shown in Fig. 0-1 on 
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P.xx, since clause 4 relates to User to Network Session Messages as stated in 
the contents on P. iii. P.28 Section 4.2.5.1 teaches the client sending a 
ClientSessionReleaseRequest {ClientReleaseRequest} message to the SRM. 
As seen on Fig. 4-7 - P.81, the client is sending and receiving messages from the 
SRM. JERDING - Paragraph 0037 teaches that the SRM can be located at the 
cable headend {digital broadcasting server}), but do not explicitly teach a ClientID 
field. 

Goffin further teaches a ClientID field (Col 3: lines 49-61 , Col 4: lines 49- 
51 teaches transmission of video from a headend and a data router 202 that 
facilitates headend communications with the client device. Col 5: lines 34-44 and 
Col 6: lines 14-24 teaches that the data router 202, receives client ID from the 
client device). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6, JERDING, and Goffin to include a 
Client ID field, as further taught by Goffin, for the advantage of allowing the 
server to easily and readily determine the source of the message. 

Consider claim 12, ISO/IEC 13818-6, JERDING, and Goffin teach 
wherein the confirmation message for confirming the session connection is a 
SessionSetupConfirm message including: a DSM-CC (Digital Storage Media- 
Command and Control) message header field, a Session ID (Identification) field, 
a response field, and a Server ID field (ISO/IEC 13818-6 - 4.2.4.2 on P 26-27, 
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and Table 4-9), and the SessionSetupConfirm message is transmitted from the 
digital broadcasting server to the client (ISO/IEC 13818-6 - "Network" referred to 
here refers to "SRM" as shown in Fig. 0-1 on P.xx, since clause 4 relates to User 
to Network Session Messages as stated in the contents on P. iii. P. 78 Steps 7 
• and 8 teaches the SRM sending a ClientSessionSetUpConfirm message to the 
client. As seen on Fig. 4-6, the client is sending and receiving messages from 
the SRM. JERDING - Paragraph 0037 teaches that the SRM can be located at 
the cable headend {digital broadcasting server}). 

Consider claim 14, ISO/IEC 13818-6, JERDING, and Goffin teach 
wherein the confirmation message for confirming the status of the client is a 
ServerStatusConfirm message including: a DSM-CC (Digital Storage Media- 
Command and Control) message header field, a Response field, a statusType 
field, a resourceNumber field for showing a number of a resource whose status is 
wanted to be known, a resourseStatus field (ISO/IEC 13818-6 - P.38-39 Section 
4.2.9.4 ClientStatusResponse {ServerStatusConfirm}; P. 60-61 teaches that 
resource descriptors may appear in a ClientStatusResponse 
{ServerStatusConfirm} message. P. 56-59 Section 4.7.1 teaches the various 
fields of a resource descriptor), and the ServerStatusConfirm message is 
transmitted from the client to the digital broadcasting server for confirming the 
status of the client (ISO/IEC 13818-6 - "Network" referred to here refers to "SRM" 
as shown in Fig. 0-1 on P.xx, since clause 4 relates to User to Network Session 
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Messages as stated in the contents on P. iii. P. 38 Section 4.2.9.4 teaches the 
client sending a ClientStatusResponse {ServerStatusConfirm} message to the 
SRM. As seen on Fig. 4-21 - P.100, the client is sending and receiving 
messages from the SRM. JERDING - Paragraph 0037 teaches that the SRM 
can be located at the cable headend {digital broadcasting server}), but do not 
explicitly teach a ClientID field. 

Goffin further teaches a ClientID field (Col 3: lines 49-61 , Col 4: lines 49- 
51 teaches transmission of video from a headend and a data router 202 that 
facilitates headend communications with the client device. Col 5: lines 34-44 and 
Col 6: lines 14-24 teaches that the data router 202, receives client ID from the 
client device). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6, JERDING, and Goffin to include a 
Client ID field, as further taught by Goffin, for the advantage of allowing the 
server to easily and readily determine the source of the message. 



Consider claim 16, ISO/IEC 13818-6, JERDING, and Goffin teach 
wherein the confirmation message for confirming a session termination is a 
ServerReleaseConfirm message including: a DSM-CC (Digital Storage Media- 
Command and Control) message header field, a session ID field, a response 
field (ISO/IEC 13818-6 - P.29-30 Section 4.2.5.4 ClientSessionReleaseResponse 
{ServerReleaseConfirm}), and the ServerReleaseConfirm message is transmitted 
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from the client to the digital broadcasting server (ISO/IEC 13818-6 - "Network" 
referred to here refers to "SRM" as shown in Fig. 0-1 on P.xx, since clause 4 
relates to User to Network Session Messages as stated in the contents on P. iii. 
P. 29-30 Section 4.2.5.4 teaches the client sending a 

ClientSessionReleaseResponse {ServerReleaseConfirm} message to the SRM. 
As seen on Fig. 4-20 - P.99, the client is sending and receiving messages from 
the SRM. JERDING - Paragraph 0037 teaches that the SRM can be located at 
the cable headend {digital broadcasting server}), but do not explicitly teach a 
ClientID field. 

Goffin further teaches a ClientID field (Col 3: lines 49-61 , Col 4: lines 49- 
51 teaches transmission of video from a headend and a data router 202 that 
facilitates headend communications with the client device. Col 5: lines 34-44 and 
Col 6: lines 14-24 teaches that the data router 202, receives client ID from the 
client device). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6, JERDING, and Goffin to include a 
Client ID field, as further taught by Goffin, for the advantage of allowing the 
server to easily and readily determine the source of the message. 



Consider claim 19, ISO/IEC 13818-6, JERDING, and Goffin teach the 
client directly requesting the digital broadcasting server for a session termination 
and terminating a session by receiving a confirmation message for the session 
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termination from the digital broadcasting server (I SO/I EC 13818-6 - "Network" 
referred to here refers to "SRM" as shown in Fig. 0-1 on P.xx, since clause 4 
relates to User to Network Session Messages as stated in the contents on P. iii. 
P. 81-82 teaches a client initiating a release request. Step 1 teaches the client 
directly sending a ClientSessionReleaseRequest message to the SRM for 
releasing an existing session. Step 4-5 teaches receiving a 
ClientSessionReleaseConfirm message from the SRM terminating the session. 
JERDING - Paragraph 0037 teaches that the SRM can be located at the cable 
headend {digital broadcasting server}. As seen on Fig. 4-7, the client is directly 
sending and receiving messages from the SRM). 

Consider claim 20, ISO/IEC 13818-6, JERDING, and Goffin teach the 
digital broadcasting server directly requesting the client for a session termination 
and terminating a session by receiving a confirmation message for the session 
termination from the client (ISO/IEC 13818-6 - P. 87 - 88, step 2 teaches 
sending a ClientSessionReleaselndication to the client for releasing an existing 
session. The SRM receives the ClientSessionReleaseResponse from the client 
and releases all the resources assigned to the session terminating the session 
for the client. As seen on Fig. 4-12, the client is directly sending and receiving 
messages from the SRM. JERDING - Paragraph 0037 teaches that the SRM 
can be located at the cable headend {digital broadcasting server}). 
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5. Claim 5 is rejected under 35 U.S.C. 103(a) as being unpatentable over ISO/IEC 
13818-6 (First edition 1998-09-01), in view of JERDING et al. (2006/0206913), in view 
of Goffin, II (US 6,918,135), and further in view of Chapman (US 7,113,484). 

Consider claim 5, ISO/IEC 13818-6, JERDING, and Goffin teach directly 
receiving, at the client, a session termination request from the digital 
broadcasting server (ISO/IEC 13818-6 - P. 99 teaches receiving a 
ClientSessionReleaselndication from the SRM for releasing session {session 
termination}. As seen on Fig. 4-20, the client is directly sending and receiving 
messages from the SRM. JERDING - Paragraph 0037 teaches that the SRM 
can be located at the cable headend {digital broadcasting server}), and 

ISO/IEC 13818-6, JERDING, and Goffin do not explicitly teach terminating 
a session if the client cannot transmit a response to the session termination 
request from the digital broadcasting server. 

In an analogous art Chapman teaches terminating a session if the client 
cannot transmit a response to the session termination request from the digital 
broadcasting server (Col 1 1 : lines 23-35 teach that if no response is received 
from the cable modem {client} the resources allocated to the session is de- 
allocated {terminated}). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6, JERDING, and Goffin to include 
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terminating a session {de-allocate resources} when no response is transmitted 
from the client, as taught in Chapman, for the advantage of freeing up resources 
for other clients. 

6. Claims 9, 11, and 15 are rejected under 35 U.S.C. 103(a) as being unpatentable 

over ISO/IEC 13818-6 (First edition 1998-09-01), in view of JERDING et al. 

(2006/0206913), in view of Goffin, II (US 6,918,135), and further in view of Lalwaney et 

al. (US 6,289,377). 

Consider claim 9, ISO/IEC 13818-6, JERDING, and Goffin teach wherein 
the message for checking the status of the client is a ServerStatusRequest 
message including: a DSM-CC (Digital Storage Media-Command and Control) 
message header field, a Reason field, a statusType field, a resourceNumber field 
for showing a number of a resource whose status is wanted to be known, a 
Reserved field (ISO/IEC 13818-6 - P.38 Section 4.2.9.2; P. 60-61 teaches that 
resource descriptors may appear in a ClientStatuslndiction 
{ServerStatusRequest} message. P.56-59 Section 4.7.1 teaches the various 
fields of a resource descriptor), and the ServerStatusRequest message is 
transmitted from the digital broadcasting server to the client (ISO/IEC 13818-6 - 
"Network" referred to here refers to "SRM" as shown in Fig. 0-1 on P.xx, since 
clause 4 relates to User to Network Session Messages as stated in the contents 
on P. iii. P. 38 Section 4.2.9.3 teaches the SRM sending a ClientStatuslndication 
{ServerStatusRequest} message to the client. As seen on Fig. 4-21 - P. 100, the 
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SRM is sending and receiving messages from the client. JERDING - Paragraph 
0037 teaches that the SRM can be located at the cable headend {digital 
broadcasting server}), but do not explicitly teach a ClientID field. 

In an analogous art Lalwaney teaches, a Client ID field (620 - Fig.6; Col 
13: lines 16-32 and Col 6: lines 50-53 teaches a packet {message} that is 
transmitted from the cable operator network to the client). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6 and JERDING to include a Client ID 
field, as taught by Lalwaney, for the advantage of easily identifying the intended 
destination of the data, helping to ensure that the intended client will receive the 
data. 

Consider claim 11, ISO/IEC 13818-6, JERDING, and Goffm teach 
wherein a message for requesting a session termination is a 
ServerReleaseRequest message including: a DSM-CC (Digital Storage Media- 
Command and Control) message header field, a session ID field, a Reason field 
(ISO/IEC 13818-6 - P.29 Section 4.2.5.3 ClientSessionReleaselndication 
{ServerReleaseRequest}), and the ServerReleaseRequest message is 
transmitted from the digital broadcasting server to the client (ISO/IEC 13818-6 - 
"Network" referred to here refers to "SRM" as shown in Fig. 0-1 on P.xx, since 
clause 4 relates to User to Network Session Messages as stated in the contents 
on P. iii. P.29 Section 4.2.5.3 teaches the SRM sending a 
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ClientSessionReleaselndication {ServerReleaseRequest} message to the client. 
As seen on Fig. 4-20 - P. 99, the SRM is sending and receiving messages from 
the client. JERDING - Paragraph 0037 teaches that the SRM can be located at 
the cable headend {digital broadcasting server}), but do not explicitly teach a 
ClientID field. 

In an analogous art Lalwaney teaches, a Client ID field (620 - Fig.6; Col 
13: lines 16-32 and Col 6: lines 50-53 teaches a packet {message} that is 
transmitted from the cable operator network to the client). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6 and JERDING to include a Client ID 
field, as taught by Lalwaney, for the advantage of easily identifying the intended 
destination of the data, helping to ensure that the intended client will receive the 
data. 

Consider claim 15, ISO/IEC 13818-6, JERDING, and Goffin teach 
wherein the confirmation message for confirming a session termination is a 
ClientReleaseConfirm message including: a DSM-CC (Digital Storage Media- 
Command and Control) message header field, a session ID field, a response 
field (ISO/IEC 13818-6 - P.29 Section 4.2.5.2), and the ClientReleaseConfirm 
message is transmitted from the digital broadcasting server to the client (ISO/IEC 
13818-6 - "Network" referred to here refers to "SRM" as shown in Fig. 0-1 on 
P.xx, since clause 4 relates to User to Network Session Messages as stated in 
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the contents on P. iii. P. 29 Section 4.2.5.2 teaches the SRM sending a 
ClientSessionReleaseConfirm {ClientReleaseConfirm} message to the client. As 
seen on Fig. 4-7 - P. 81, the SRM is sending and receiving messages from the 
client. JERDING - Paragraph 0037 teaches that the SRM can be located at the 
cable headend {digital broadcasting server}), but do not explicitly teach a ClientID 
field. 

In an analogous art Lalwaney teaches, a Client ID field (620 - Fig.6; Col 
13: lines 16-32 and Col 6: lines 50-53 teaches a packet {message} that is 
transmitted from the cable operator network to the client). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6 and JERDING to include a Client ID 
field, as taught by Lalwaney, for the advantage of easily identifying the intended 
destination of the data, helping to ensure that the intended client will receive the 
data. 

7. Claim 13 is rejected under 35 U.S.C. 103(a) as being unpatentable over ISO/IEC 
13818-6 (First edition 1998-09-01), in view of JERDING et a\. (2006/0206913), and 
further in view of Lalwaney et al. (US 6,289,377). 

Consider claim 13, ISO/IEC 13818-6 teaches a method for controlling 
network digital broadcasting service (P. xix [0. Introduction], 2 nd paragraph, 
Described further in detail in Clause 4), comprising steps of: 
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directly requesting, at a client, a SRM (Session Resource Manager) for a 
session connection, and establishing a session by receiving a confirmation 
message for the session connection from the SRM ("Network" referred to here 
refers to "SRM" as shown in Fig. 0-1 on P.xx, since clause 4 relates to User to 
Network Session Messages as stated in the contents on P. iii. P. 76 Step 1 
teaches "the Client shall send ClientSessionSetUpRequest to the Network..." to 
establish a new session connection. P. 78 Steps 7-8 teaches the client receiving 
a ClientSessionSetUpConfirm message from the SRM establishing the session 
connection. As seen on Fig. 4-6, the client is directly sending and receiving 
messages from the SRM); and 

directly requesting, at the client, the digital broadcasting server for a 
channel change, and changing a channel by receiving a confirmation message 
for confirming the channel change from the digital broadcasting server (P. 492- 
495 teaches a client directly requesting a broadcast program from the SDB 
Server. A SDBProgramSetectRequest is generated by the client and sent to the 
SDB Server for requesting a channel change. A SDBProgramSelectConfirm 
from the SDB Server is received by the client allowing the client to receive the 
requested Broadcast Program), 

wherein a message for requesting the channel change and the 
confirmation message for confirming the channel change each include a DSM- 
CC (Digital Storage Media-Command and Control) message header field (P. 
492-493; Fig. H-4. protocolDiscriminator, dsmccType, messageld, transcationld, 
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reserved, adaptationLength, messageLength make up a DSM-CC message 
header field as taught in clause 2 on p. 7, which are all present in both messages 
for channel change and confirmation. P.291 Sections 10.1.2-10.2), the 
confirmation message for confirming the channel change is a 
ProgramSelectConfirm message including: a DSM-CC (Digital Storage Media- 
Command and Control) message header field (P. 492-493; Fig. H-4. 
protocolDiscriminator, dsmccType, messageld, transcationld, reserved, 
adaptationLength, messageLength make up a DSM-CC message header field as 
taught in clause 2 on p. 7, which are all present in both messages for channel 
change and confirmation. P.291 Sections 10.1.2-10.2), a Session ID 
(Identification) field, a response field, a broadcast Programld field, and the 
ProgramSelectConfirm message is transmitted from the digital broadcasting 
server to the client (Table 10-6, P.293 Section 10.2.3.2), 

privateData() field contains connection information necessary for the 
Client to receive the broadcast program (P.293 Section 10.2.3.2). 

ISO/IEC 13818-6 does not teach that the SRM (Session Resource 
Manager) can also reside at the digital broadcaster server, 

the ProgramSelectRequest message includes a Client ID field. 

In an analogous art JERDING teaches session setup and controlling video 
distribution between server and client. JERDING also teaches a SRM (Session 
Resource Manager) that resides at the digital broadcaster server (cable 
headend) (Fig. 2, Paragraph 0037 teaches where both the MOD application 
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server 19 and the digital network control system {DNCS, SRM} are both located 
at the cable television headend 11). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6 to include the SRM at the cable 
headend, as taught by JERDING, for the advantage of providing the cable 
service providers with greater control and manageability over the broadcasting 
infrastructure. 

ISO/IEC 13818-6 and JERDING teaches a ProgramSelectConfirm 
message (ISO/IEC 13818-6 - P.293 Section 10.2.3.2) that also contains a 
privateData field that contains connection information necessary for the Client to 
receive the broadcast program (ISO/IEC 13818-6 - P.293 Section 10.2.3.2), but 
do not explicitly teach the message includes a Client ID field. 

In an analogous art Lalwaney teaches, a Client ID (620 - Fig.6; Col 13: 
lines 16-32 and Col 6: lines 50-53 teaches a packet {message} that is transmitted 
from the cable operator network to the client). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6 and JERDING to include a Client ID 
field, as taught by Lalwaney, for the advantage of easily identifying the intended 
destination of the data, helping to ensure that the intended client will receive the 
data. 
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8. Claim 18 is rejected under 35 U.S.C. 103(a) as being unpatentable over ISO/IEC 
13818-6 (First edition 1998-09-01) in view of JERDING et al. (2006/0206913), in view of 
Goffin, II (US 6,918,135), and further in view of Yun (US 2007/0006254). 

Consider claim 18, ISO/IEC 13818-6, JERDING, and Goffin teach the 
client receiving a message from the digital broadcasting server for checking a 
status of the client (ISO/IEC 13818-6 - P. 100 teaches receiving a 
ClientStatuslndication message from the SRM for requesting {checking} a status 
of the client. JERDING - Paragraph 0037 teaches that the SRM can be located 
at the cable headend {digital broadcasting server}), and directly delivering a client 
status confirmation message, indicative of the status of the client, to the digital 
broadcasting server (ISO/IEC 13818-6 - P. 100 teaches the client sending a 
ClientStatusResponse message directly to the SRM containing status data of the 
client. As seen on Fig. 4-21, the client is directly sending and receiving 
messages from the SRM. JERDING - Paragraph 0037 teaches that the SRM 
can be located at the cable headend {digital broadcasting server}). 

ISO/IEC 13818-6, JERDING, and Goffin do not explicitly teach the client 
periodically receiving a message from the digital broadcasting server for 
checking a status of the client. 

In an analogous art Yun also teaches the client periodically receiving a 
message from the digital broadcasting server for checking a status of the client 
(Paragraph 0090 teaches the cable head end transmitting the command 
{message} for periodically checking the operation state {status} of the set-top box 
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{client}. The client {POD and set-top box} periodically receives these commands 
are sent periodically from the server to the client side). 

Therefore, it would have been obvious to a person of ordinary skill in the 
art to modify the system of ISO/IEC 13818-6, JERDING, and Goffin to have the 
client periodically receive messages from the digital broadcasting server for 
checking a status of a client, as taught by Yun, for the advantage of providing the 
head end {digital broadcasting server} information regarding the set-top box in 
realtime (Yun - Paragraph 0073) and providing the head end with a more 
competitive edge (Yun - Paragraph 0035 - 0036). 
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Conclusion 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Jason K. Lin whose telephone number is (571)270- 
1446. The examiner can normally be reached on Mon-Fri, 9:O0AM-6:0OPM, EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Brian T. Pendleton can be reached on (571)272-7527. The fax phone 
number for the organization where this application or proceeding is assigned is 571- 
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